1. Field of the Invention
This invention relates to a method and apparatus for optimizing the handling of a synchronous request issued from a requester to a request handler and, more particularly, to a method and apparatus for optimizing the handling of a synchronous request issued from a system partition of a logically partitioned machine in a sysplex configuration.
2. Description of the Related Art
Many computer hardware machines conforming to the IBM.RTM. S/390.RTM. architecture, as described, for example, in the IBM publication Enterprise Systems Architecture/390 Principles of Operation, SA22-7201-02, Dec. 1994, incorporated herein by reference, operate in what is known as logically partitioned (LPAR) mode. Logically partitioned computer systems are well known in the art and are described in Guyette et al. U.S. Pat. No. 4,564,903, Bean et al. U.S. Pat. No. 4,843,541, and Kubala U.S. Pat. No. 5,564,040, incorporated herein by reference. Commercial embodiments of logically partitioned systems include IBM S/390 processors with the Processor Resource/Systems Manager.TM. (PR/SM.TM.) feature and described, for example, in the IBM publication Processor Resource/Systems Manager Planning Guide, GA22-7236-01, June 1997, incorporated herein by reference.
Logical partitioning allows the establishment of a plurality of system images within a single physical machine, or central processor complex (CPC). Each system image is capable of operating as if it were a separate computer system. That is, each logical partition can be independently reset, initially loaded with an operating system that may be different for each logical partition, and operate with different software programs using different input/output (I/O) devices. Logical partitioning is in common use today because it provides its users with flexibility to change the number of logical partitions in use and the amount of physical system resources assigned to each partition, in some cases while the entire central processor complex continues to operate.
A recent addition to the IBM S/390 architecture, usually operating in a logically partitioned environment, is the IBM Parallel Sysplex.TM. configuration, comprising two or more systems interconnected via a coupling facility to form what is known as a "sysplex" (for "system complex"). A sysplex configuration may have more than one coupling facility, for example a backup coupling facility set to take over if a primary coupling facility fails. Each system that is a member of a sysplex may be either a separate hardware machine or a separate logical partition of a particular hardware machine. In a similar manner, each coupling facility in the sysplex may be either a separate hardware machine or a separate logical partition of a particular hardware machine.
In the S/390 Parallel Sysplex architecture, a system issues a request to a coupling facility using a Send Message (SMSG) instruction. This instruction is executed by a central processor (CP) of the machine on which the system resides; this CP may be a logical CP if the system resides in a logical partition. The executing CP causes a message command block (MCB) to be sent along a message path to the coupling facility and receives back a message response block (MRB) containing the results of the request. Message communication and other aspects of the operation of an S/390 coupling facility are described in such references as Elko et al. U.S. Pat. No. 5,561,809, Elko et al. application Ser. No. 08/147,697, filed Nov. 4, 1993, and the patents and applications referred to therein, all incorporated herein by reference .
SMSG instructions may be executed either synchronously or asynchronously. When executed asynchronously, the SMSG instruction is competed as soon as the request in the form of a MCB is sent off to the target coupling facility. When executed synchronously, on the other hand, the SMSG instruction is not completed until a response in the form of an MRB is received back from the target facility.
There are many situations where it is advantageous for a SMSG instruction to be executed synchronously. This presents a problem, however, if both the system and the coupling facility receiving the request reside on different logical partitions on the same physical machine with shared CPs. As noted above, a synchronous SMSG instruction is not completed until the executing CP has received a response back from the target coupling facility; until the command is completed, the executing CP is not free to do other work. However, if the coupling facility needs the same physical CP to execute the request at its end, a deadlock will result since the CP is being held by the requesting system.
Currently, to avoid this problem, if a system that is a member of a Parallel Sysplex configuration is running in a logical partition that uses shared CPs and there is a coupling facility (CF) partition on that same machine that also uses shared CPs, all coupling facility (SMSG) requests from that logical partition ("system partition" hereinafter) are converted to asynchronous requests; there is no determination of whether the system partition is even connected to an inboard shared-CP coupling facility, much less whether it is issuing a request to that facility. Even if this determination is made, the mechanism used to accomplish this, known as the synchronous override Start Interpretive Execution (SIE) state descriptor control, is all or nothing for a particular system partition: if the partition accesses both an inboard and an outboard CF, all requests are converted to asynchronous requests to accommodate the inboard CF.
FIG. 1 shows the current environment, in which a system partition MVS.sub.-- A accesses both an outboard coupling facility CF.sub.-- A with dedicated processors and an inboard coupling facility CF.sub.-- B. Both the system partition MVS.sub.-- A and the inboard coupling facility CF.sub.-- B are running with shared CPs. All requests from MVS.sub.-- A to either CF are converted to asynchronous requests to avoid the deadlock problem, regardless of the identity of the target facility.
While this mode of operation avoids deadlocks, it can lead to situations where synchronous SMSG requests to an external or otherwise dedicated coupling facility are being needlessly being converted into asynchronous requests. This results in a performance hit to these converted commands as well as driving up system assist processor (SAP) utilization to handle all the requests as asynchronous.
Shared CPs have been used relatively infrequently for coupling facilities up until now, so the exposure so far has been rather limited. However, with recent advances in coupling facility technology, shared CPs for a coupling facility have become an attractive option, especially for a hot-standby CF. These configurations will very naturally have a hot standby CF using shared CPs on the same physical machine as one or more system partitions that are sysplex members. These system partitions will also be attached to the primary external CF. It is important that a high level of performance be maintained in this environment. What is desired is a mechanism for allowing requests that can go synchronous (to the external CF) stay synchronous and only cause requests from an internal shared system CP to a shared CF CP be converted to asynchronous.
Currently, on an S/390 processor in logically partitioned mode, the logical partition manager or hypervisor (LPAR in FIG. 1) monitors changes in the current active configuration of a single CPC during activation and deactivation of coupling facility logical partitions. If a CF with real links and shared CPs is activated, a mark is put on the wall to set all system partitions with shared CPs to convert synchronous SMSG requests to asynchronous requests unconditionally. This is done by setting a single bit in the SIE state descriptors for the system partitions, which CP microcode checks for all SMSG requests from the partition. This conversion is done to avoid the problems of trying to complete a synchronous SMSG request that needs the same CP to dispatch the CF on to complete the request.
Actual monitoring of the connectivity of the links attached from a given system partition would be a rather involved task for a logical partition manager to undertake, especially when considering all the dynamic aspects of the configuration, including channel path reconfiguration and dynamic I/O.